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device. The image producing portion of the client machine uses the limited resources of the client in 
order to continue generating or analyzing additional images. For this reason, images are placed in a 
queue for eventual transfer to the server device. Due to issues such as network congestion or the rapid 
generation of images, the queue can overflow. Under these conditions, our invention describes a series 
of steps to prevent images from being permanently discarded and lost. Tanaka describes completely 
different subject matter. A detailed reading of Tanaka against our invention will show that the similarity 
between the two is limited to transmitting digital images on a network. The image manipulation 
performed by Tanaka is fundamentally different and for different purposes than described by our 
invention. 

I will now address your issues on a claim by claim basis. 
Claim 1, the steps, 

• optionally making a copy of the image to free up system resources on the client; 

• placing a copy of the image in a client queue if the image cannot be transmitted immediately; 

You claim these are covered by Tanaka (col 5, lines 47-55), saying "Tanaka discloses a relay server 
accumulating pieces of the image data before it goes to the archiver." 

Tanaka is describing a data cache to accumulate data prior to transferring the image data to the terminal. 
The purpose of the cache is to temporarily store the received image data for retransmission. Tanaka does 
not describe making a copy of the image on the relay server, archiver, or database. In our invention, the 
creation of a copy is important, because the client device can reuse the image storage for other purposes. 
For example, if the client device is a machine vision system, the image buffer now becomes available to 
hold another image to be inspected. The image copied to the image queue will be potentially altered 
prior to transmission to the server. 
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Claim 1, the steps, 

• measuring the client resource availability of local resources and available processor time and maintaining 
historical information and trends; 

• measuring the status and performance of the network connecting the client device and server device, and 
maintainin g historical information and trends; 

You claim these are covered by Tanaka (col. 6, lines 49-56, col. 10, lines 4-15). In our specification we 
define resource. availability as, "Resource availability 315 is a combination of current resource 
information as well as historical information and trends. The client transfer mechanism 320 uses this 
information to decide the amount of resources available to manipulate the image prior to transmission. 
Resource availability 315 also includes information regarding the availability of image analysis specific 
resources such as frame buffers and image buffers." The Tanaka references you cite refer to using 
multiple servers to handle requests from the terminals, and solves a completely different problem. There 
is no mention in Tanaka to describe this portion of the claim. Also, there is no mention in Tanaka 
regarding the use of historical information and trends to estimate the availability of the network to 
transfer image data. It might be helpful to note that Tanaka uses multiple servers to distribute the load of 
handling requests. In our invention, a single client device has only its internal resources at its disposal to 
attempt to transfer all image data to a server device. 

Claim 1, the step, 

• increasing the size of the client queue if it becomes full; 

You admit this is not covered by Tanaka, but assert that it is disclosed by Dobbelstein (5,881,269). 
Contrary to your assertion, a person of ordinary skill would be unable to connect both patents. Tanaka 
never mentions the possibility of failure of processing a request. The only reference by Tanaka states, 
"Further even if one of the relay servers fails, the other relay servers can act for the fault relay server" 
(col 4., lines 10-12). In this context, Tanaka is referring to what a load balancer does; using multiple 
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servers to handle a request if one of the servers fails (i.e. stops running). Tanaka does not discuss 
anything to prevent a request on an individual server from failing because of queue size. Presumably, a 
system patterned after Tanaka will crash under these conditions, causing the loss of any information on 
the server. Thus, Tanaka neither teaches nor suggests either the problem or the resolution to the problem 
as claimed in Claim 1. Dobbelstein is not directed to solving any problem related to image manipulation 
or image transfer. As a result, a person of ordinary skill in the art of image manipulation or image 
transfer would not look to Dobbelstein for any purpose related to image manipulation. Dobbelstein does 
disclose increasing the size of a queue to prevent a network emulator from failing. However, the context 
of Dobbelstein's invention is simulating multiple users on a network with a single workstation, not 
image manipulation. Given that Tanaka does not address the problem or solution regarding queue size, 
and Dobbelstein is discussing a completely different subject area, it is not obvious to modify Tanaka in 
view of Dobbelstein. 

Claim 1, the step, 

• reducing the size of images to conserve storage space in the queue or to reduce transmission time between the 
client and server; 

You claim this is covered by Tanaka (col. 10, lines 53-65). Tanaka describes two things. The first is to 
convert an image into a format compatible with a web browser. The second is to compress the image if 
the data size is too large. With Tanaka, the conversion of the image uses a predetermined format. The 
conversion is fixed or negotiated between the server and the terminal (i.e. web browser). In our 
invention, a set of rules is imposed to preserve both the image resolution and content. However, the 
image will be permanently and destructively altered, if necessary, to insure that the server device can 
receive the image given the current network performance and conditions of the client device queue. 
Tanaka takes an archived image and converts it for display. The original image is not altered in any way. 
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Our invention deals with volatile images that will be deleted unless a means is found to persist them 
until such time they can be transmitted to a server device. Tanaka does not use image reduction to 
conserve storage space in a queue; Tanaka uses compression to satisfy a requirement of the web 
browser. Tanaka makes no mention that size reduction will reduce transmission time; Tanaka states that 
compression is only performed when "the medical image data is too large in data size." 

Claim 2 

A system according to claim 1, wherein the step of increasing the size of the client queue includes an upper limit to prevent 
the queue from growing beyond a specified size. 

You claim this is covered by Tanaka (col 10, lines 18-52). However, Tanaka only mentions that some or 
all protocol conversion servers can be equipped with a cache. In our invention, the upper limit of the 
queue size is to prevent it from increasing without bound. On page 3 of your most recent response you 
admit that Tanaka fails to include mention of increasing the size of the client queue. Therefore, Tanaka 
does not discuss setting an upper bound on the queue size. 

Claim 3 

A system according to claim 1, wherein the step of transferring the signal from the client to the server can include encrypting 
the information on the client prior to transmission and decrypting the data once it is received by the server 

You argue that claim 3 is unpatentable over Tanaka in view of Glass because Tanaka teaches the method 
of claim 1. On page 3 of your most recent response you admit that Tanaka does not fully address claim 1 
saying, "Tanaka fails to teach the limitation further including increasing the size of the client queue if it 
becomes full." 

Claim 4 

A system according to claim 1, wherein the step of transferring the image signal from the client to the server can comprise: 

• transmitting image data from one or more clients to a gateway server, such that the clients consider the gateway 
server to be a server; 

• buffering the image data on the gateway server; 
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• transmitting image data from the gateway server to the server, such that the server considers the gateway server to 
be a client. 



Your argument against claim 4 is moot because they are based on claim 1. Claim 1 is not described by 
Tanaka as you indicate. 



Claim 5 

A system according to claim 1, wherein the step of reducing the size of an image comprises: 

• selecting one or more reduction methods to reduce the image size from a plurality of lossless or lossy compression 
methods; 

• reducing the current image, or any image in the queue when the queue becomes full; 

• periodically reducing the size of the images in the queue, using reduction methods when processor resources are 
available. 



Claim 6 

A system according to claim 5, wherein the step of selecting one of more reduction methods comprises: 

• estimating the reduction in image size possible for a specific reduction method; 

• estimating the cost of this reduction where the cost includes the resources required for reduction as well as the 
time to reduce the image; 

• performing the reduction if the cost is allowable and the reduction is considered meaningful; 

• evaluating other reduction methods if the desired amount of reduction has not been achieved. 

Your argument against claims 5 and 6 uses the same Tanaka reference from the 7th step of claim 1 (col 
10, lines 53-65). Claim 5 and 6 describe specific actions taken to reduce image size, including 
"periodically reducing the size of the images in the queue, using reduction methods when processor 
resources are available," and "performing the reduction if the cost is allowable and the reduction is 
considered meaningful." Tanaka only describes compression for displaying images in a predetermined 
format. Tanaka does not describe the reduction techniques of claims 5 and 6. 



Claim 7 

A system according to claim 6, wherein the step of determining if the cost is allowable comprises: 

• checking the current system resources to see if sufficient resources and time are available to reduce the image; 

• checking historical system resources and trends to estimate future resource availability; 

• checking the current network parameters such as available bandwidth and throughput; 

• checking historical network conditions and trends to estimate future network conditions. 
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You reference Tanaka (col 6., lines 49-56, col. 10, lines 4-15) as describing if the cost of image 
reduction is allowable, given current system and network load. Tanaka describes something different; 
using multiple servers instead of one in order to affect high efficiency. Multiple servers will not solve 
the problem describes in claim 7 as the image resides on a single server, and must be transmitted over a 
network to a server device. 

Claim 8 

A system according to claim 1, wherein the step of transferring the image signal from the client device to the server device 
comprises: 

• storing the received image in a server queue or on a networked file system; 

• increasing the size of the server queue if it becomes full; 

• reducing the size of images to conserve storage space in the queue or to reduce storage requirements in the 
image database. 

You reference Tanaka (col. 10, lines 18-39) as describing increasing the size of the server queue if it 
becomes full. However, on page 3 of your most recent response you admit that Tanaka fails to include 
mention of increasing the size of the client queue. 

Claim 8 also specifies "reducing the size of images to conserve storage space in the queue or to reduce 
storage requirements in the image database." You reference Tanaka (col. 10, lines 53-65) as prior art. 
However, Tanaka describes image reduction if the image exceeds a specified size and for compatibility 
for display in a web browser. In our invention, the image size can be reduced in order to consume less 
space in the server database. 

Claim 9 

A system according to claim 8, wherein the step of increasing the size of the server queue includes an upper limit to prevent 
the queue from growing beyond a specified size. 

You use Tanaka (col. 10, lines 18-52) to describe the step of increasing the size of the server queue 
includes an upper limit to prevent the queue from growing beyond a specified size. However, on page 3 

Page 8 of 19 



Response to Office Action Application/Control Number: 09/9 1 1 ,090 



of your most recent response you admit that Tanaka fails to include mention of increasing the size of the 
client queue. 



Claim 10 

A system according to claim 8, wherein the step of reducing the size of an image comprises: 

• selecting one or more reduction methods to reduce the image size from a plurality of lossless or lossy 
compression methods; 

• reducing the current image, or any image in the queue when the queue nears or becomes full; 

• periodically reducing the size of the images in the queue, using lossless compression methods when processor 
resources are available. 

Claim 11 

A system according to claim 10, wherein the step of selecting one of more reduction methods comprises: 

• estimating the reduction in image size possible for a specific reduction method; 

• estimating the cost of this reduction where the cost includes the resources required for reduction as well as the 
time to reduce the image; 

• performing the reduction if the cost is allowable and the reduction is considered meaningful; 

• evaluating other reduction methods if the desired amount of reduction has not been achieved. 

You reference Tanaka (col. 10, lines 53-65) to refute our claim of reducing image size when the queue 
becomes full, "periodically reducing the size of the images in the queue, " or estimating the cost of 
reduction vs. the time required to reduce the image. Tanaka describes the compression of images to a 
predetermined format for display. Tanaka does not describe any methodology or process to select how 
and when images are reduced, and whether the reduction results in a lossless or lossy image reduction. 
Tanaka also does not discuss this in context of preventing a queue from overflowing. Further, Tanaka 
does not discuss the automatic reduction in image size when processor time is available. 



Claim 12 

A system for transmitting digital image signals from a client device to a server device, comprising: 

• establishing a connection between one or more client devices and server device; 

• optionally making a copy of the image to free up system resources on the client; 

• dividing the available network bandwidth between the client and server into one or more pieces and assigning 
certain images to be transmitted using these reserved channels; 

• placing a copy of the image in a client queue if the image cannot be transmitted immediately; 

• measuring the client resource availability of local processor resources and available processor time, and maintaining 
historical information and trends; 

• measuring the status and performance of the network connecting the client device and server device, and 
maintaining historical information and trends; 

• increasing the size of the client queue if it becomes full; reducing the size of images to conserve storage space in the 
queue or reduce transmission time between the client and server; 
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• transferring the image from the client device to the server device; 

• persisting the image on the server device until it is processed or saved. 

Claim 12 can be analyzed like Claim L There is one additional step, "dividing the available network 
bandwidth between the client and server into one or more pieces and assigning certain images to be 
transmitted using these reserved channels." You cite Tanaka (col. 5 5 lines 47-55) as "disclosing using 
different relay servers and piecing the image". However, this section of Tanaka describes using a cache 
to accumulate pieces of medical image data to be transmitted to a terminal. Tanaka makes no mention of 
reserving bandwidth between client and server and assigning certain images to use this reserved 
bandwidth. 



Claim 13 

A system according to claim 12, wherein the step of reserving network bandwidth comprising: 

• specifying the mapping of image type to a reserved piece of network bandwidth; 

• using any remaining, unreserved network bandwidth for images that do not have any defined mapping; 

• allocating a separate queue for each piece of network bandwidth or allocating elements from a single queue; 

• identifying the type of image and routing this image to the appropriate piece of network bandwidth or queue; 



You cite Tanaka (col. 9, lines 1-37) as disclosing using different servers for different types of image 
data. However, claim 13 describes the assignment of network bandwidth based on image type and 
importance. The assignment of bandwidth is very different than the assignment of server. In a single 
client, single server environment you can still assign network bandwidth such that higher priority images 
have a greater chance of being transmitted to the server. Tanaka only teaches that multiple servers be 
used to affect higher efficiency and does not discuss reserving network bandwidth for specific purposes. 



Page 10 of 19 



